Sixth Framework Programme Priority Ist-2002-2.3.1.4 Mobile and Wireless Systems beyond 3g D 7.2 Ambient Network Security Architecture Annex 4 Quick Nap -secure and Efficient Network Access Protocol

Current network access protocol stacks consist of a number of layers and components that are only loosely aware of each other. While this provides flexibility, it also results in a number of limitations, including high signalling latency due to duplicated tasks at multiple layers, security vulnerabilities, and deployment problems when new components and protocols are added. Most of currently ongoing work attempts to improve the network access protocols through enhancements in different parts of the stack, such as network access authentication or mobility protocols. We take a different approach in this paper by focusing on opportunities that arise when the network access problem is viewed as a whole as opposed to focusing on a single layer. By taking this cross-layer viewpoint we are able to significantly reduce the number of roundtrips and enable the secure integration of new components such as mobility, NATs, firewalls, and quality of service signaling in a way that makes the deployment of these new components easier. 1 Dissemination level as defined in the EU Contract: PU = Public PP = Distribution limited to 6 FP participants RE = Distribution to a group specified by the consortium CO = Confidential, only allowed for members of the consortium Security Type: Confidential Internal circulation within project (and Commission project Officer if requested) Restricted Restricted circulation defined in the document or dissemination level PP Internal With no confidential content but intended for internal use Public Public document Document: IST-2002-507134-AN/WP7/D02 Date: 2005-12-29 Security: Public Status: Final Version: 1.0 WWI Ambient Networks PUBLIC INFORMATION 2(14) Table of contents 1.1 Background..................................................................................................................3 1.2 Problem Definition........................................................................................................3 1.3 The New Architecture ..................................................................................................5 1.4 The New Protocol ........................................................................................................7 1.4.1 Basic Exchange....................................................................................................7 1.4.2 Advanced IPv6 Services.......................................................................................8 1.4.3 IPv4 Web-Based Login with Firewalls ..................................................................9 1.5 Evaluation ..................................................................................................................10 1.5.1 Related Work ......................................................................................................11 1.6 Conclusions ...............................................................................................................11 1.7 References.................................................................................................................12 Document: IST-2002-507134-AN/WP7/D02 Date: 2005-12-29 Security: Public Status: Final Version: 1.0 WWI Ambient Networks PUBLIC INFORMATION 3(14) 1.1 Background In network access, several steps need to be performed before a device has sufficient end-toend connectivity for its applications. In IEEE 802.11 networks, for example, these steps include detection of network, authentication and association at layer-2, IP address assignment, and router discovery. Additional steps are required for mobile nodes that move between subnets, or in situations where there is a need to interact with quality of service mechanisms or middleboxes such as NATs or firewalls. Treating these steps independently of each other results in a number of shortcomings. For instance, in wireless LANs network attachment can introduce latency, as it consists of a large number of steps that have to be performed in sequence and with some mandatory delay periods. Current protocols also have a number of security vulnerabilities. In addition, different components may require separate security infrastructure and configuration. This can lead to vulnerabilities since actions in different components are not bound together, and the deployment of security for features such as quality of service is often discouraged. These problems are discussed in more detail later. Ongoing work attempts to optimize and improve this situation through enhancements in different parts of the stack, such as network access authentication or mobility protocols. This follows a common research and engineering approach in networking where designers typically focus on a specific problem at a time. This paper presents a new architecture, Quick NAP (or NAP for short), that deviates from current network attachment designs. We claim that instead of focusing on a single layer (for example, the link layer) or a single function (such as authentication), it is necessary to look at the problem as a whole: What tasks are necessary in order to have a node attach to a network? How can that node move from one point of attachment to another? Which nodes need to communicate with what other nodes, and when? What is the best order of the tasks so that the number of roundtrips is minimized? By taking this cross-layer viewpoint we are able to significantly reduce the number of roundtrips and enable the secure integration of new components such as mobility, firewalls, and quality of service signaling in a way that makes the deployment of these new facilities easier. The following sections describe our proposed architecture and protocol interaction in more detail. Finally, we will discuss the characteristics of NAP, some other approaches for solving the same problems, and conclude our findings. 1.2 Problem Definition Figure 1 shows an example network attachment message flow from a 802.11 wireless LAN and IPv6 scenario. This flow consists of access point discovery, link layer association, authentication, IP address assignment, router discovery, and mobility tasks. Put together there are 27 messages in the complete flow, along with several mandatory waiting periods (such waiting up to a second before sending the first IPv6 Neighbour Discovery packet). Assuming that all functions such as mobility are necessary, this flow is still optimistic: in practise there are more messages and larger delays [Alimian]. For instance, many EAP methods have a higher number of roundtrips than what is shown here. Document: IST-2002-507134-AN/WP7/D02 Date: 2005-12-29 Security: Public Status: Final Version: 1.0 WWI Ambient Networks PUBLIC INFORMATION 4(14) Figure 1. Current WLAN and IPv6 attachment. Some of the factors that have led to the current design include sequencing without real causal link between messages, duplicated security at multiple layers, and assumptions that focused on wired networks. But the organizatorial structure of the standards bodies that developed these protocols is also visible in the end result; its also clear that no single group has felt responsible for the ownership of the whole problem. Current stacks also have security vulnerabilities. Simple examples of these vulnerabilities relate to individual problems within a single protocol. For instance, protocols such as 802.1X, EAP, 802.11, or 802.11i are not very resistant to denial-of-service attacks and are also not very good in providing identity privacy for the participants. In addition, different components are today typically expected to use independent security solutions. This can lead to vulnerabilities since actions in different components are not bound to each other. For instance, network access authentication mechanisms can ensure that a client talks to an authorized access point, and SEcure Neighbour Discovery (SEND) can ensure that the same client talks to an authorized router. However, even with SEND there is no guarantee that the router is authorized to act in this specific access network. In fact, clients will readily accept Router Advertisements from any SEND router as there is no binding between the access network and routers. This is problematic in shared media links such as 802.11. For instance, a compromised SEND router from anywhere in the world may claim to be a local router. Another reason for binding multiple functions together relates to address ownership. For instance, opening pinholes in a NAT or a firewall, mobility protocol registrations, and quality of service reservations all need to prevent malicious registrations and modifications by outsiders. An ability to show the ownership of an address, such as the validity of your DHCP lease, would make it possible to secure these functions in a convenient manner. A more serious problem is the expectation to deploy different security infrastructures for different functions of the stack. In practise, it is often feasible to deploy only a single infrastructure and perform a single configuration effort for network access purposes. As a Document: IST-2002-507134-AN/WP7/D02 Date: 2005-12-29 Security: Public Status: Final Version: 1.0 WWI Ambient Networks PUBLIC INFORMATION 5(14) result, security may not be turned on or used even where protocol mechanisms and implementations already exist. For instance, DHCP authentication has been defined in [RFC3118] but has not been deployed [Droms]. This problem affects not only the security of existing services such as DHCP, but also prevents the deployment of new functions. For instance, the FMIP mobility optimization assumes the existence of security associations to local routers [FMIP]. One of the reasons why FMIP is currently not deployed relate to this assumption; configuring such security associations would be costly. An attachment to a network consists of a transaction between the mobile node, access point, access router, access network, home network, possibly some mediating networks, and possibly also some mobility related nodes such as home agents. Some of these entities, such as access networks, can not be explicitly communicated with in current network architectures. Similarly, the communication mechanisms that are available between these parties are mostly focused on the initial attachment and may not be available during subsequent communications. Even during the initial attachment, current protocols typically achieve secure communications at the very end of the long flow. As a result, the capability of the protocol stack to exchange necessary information in a heterogeneous multi-access scenario is limited. 1.3 The New Architecture Our design targets all activities needed for network attachments and movements. The architecture operates either in an ad hoc network or uses a single security infrastructure for all of its activities. It also employs a number of techniques for reducing latency, and provides a highly secure operation through employing modern cryptographic protocol design, denial-ofservice and privacy protection, and secure identification. At the network level, the NAP architecture retains the current design where clients communicate with access nodes and with home networks through access nodes. However, we introduce a new way to address and communicate securely with other devices in the access network (such as DHCP servers), middleboxes, or mediating networks. These communications can take place at any time, for handoff guidance or advice of charge purposes, for instance. At the protocol level, we provide a new message flow that combines link layer and network layer control functions within the same messages, though still enabling a separation between these layers and the devices responsible for them. NAP operates in one of two security modes, either in the ad hoc or infrastructure modes. The protocols behave very similarly in these two modes, but authorization and payment for network access can occur only in the infrastructure mode. Nevertheless, even the ad hoc mode is cabable of protecting on-link communications and signaling with middleboxes and other devices belonging to the access network. This protection is possible through the use of cryptographically generated identifiers at link and network layers. The involved devices are explicitly identified by a hash of their public keys. These hashes replace conventional MAC addresses, and serve as a convenient mechanism to bind the entities to their identities securely. This works well even in the ad hoc mode, even if the trustworthiness or authority of the device represented by its identifier can not be guaranteed. This method can still provide opportunistic security, however. For instance, communications between a client and an access node are protected from outsiders, and handoffs to another interface of the same access node can be made securely. The public keys of the nodes can be generated by themselves and do not need any security infrastructure. User identities (such as NAIs [NAI]) and IP addresses are kept as they are currently. We also expect there to be a need to continue the use of legacy credentials through protocols such as EAP. Once the network attachment and authorization is finished a number of further protocols may need to be executed, including stateless or stateful address configuration procedures, mobility management protocols, QoS signaling protocols, application layer signaling protocols (such as Document: IST-2002-507134-AN/WP7/D02 Date: 2005-12-29 Security: Public Status: Final Version: 1.0 WWI Ambient Networks PUBLIC INFORMATION 6(14) SIP), etc. Our architecture deals with these protocols in two ways. First, we can create keying material, parameters and authorization related information to efficiently secure other protocols. This is similar to what has been proposed in [Bootstrapping] for bootstrapping DHCP, in [mipv6-bootstrapping] for bootstrapping of MIPv6, and in [Keys] for bootstrapping in FMIPv6. Secondly, for performance, tasks can be delegated to the network devices, reducing expensive radio roundtrips. These tasks need not be related to the link layer processing only. For instance, the mobile node can request the access node to allocate an IP address or inform the mobile node's home agent about the currently used care-of address. The mobile node provides the basic information necessary to perform these tasks (such as interface identifier) and, depending on the task, signs a certificate to delegate the right for this specific task to the access node, making various delegated tasks possible (cf. [Faria]). To illustrate our architecture, we sketch a possible protocol run: 1. The access node sends a beacon message, identifying itself with the hash of its public key. It can also send along a small amount of information affecting the attachment decision, such as what payment models it supports, what roaming partnerships it has, what subnets offering fast roaming are provided, etc. 2. The client and the access node initiate an attachment procedure. A Diffie-Hellman exchange is run as early as possible to protect all subsequent communications, including all management operations and negotiations. This also enhances the privacy of the subsequent communications against eavesdroppers on the wireless link. This procedure provides also secure negotiation of capabilities. In this phase, the client and the access node also authenticate opportunistically the claimed hash-based identities to ensure that the peer actually knows the private key corresponding to the public key used in the hash (similar to how HIP [HIP] or BTNS [BTNS] operates). This can not demonstrate who we are communicating with, but ensures that we are talking with the same entity all the time. 3. Within the above exchange, we can also initiate a third party authentication and authorization exchange, if needed. Usually this involves the use of protocols such as EAP and RADIUS to authenticate the client to an existing AAA infrastructure. Note that unlike some other proposals, we do not assume that existing authorization models or AAA can be replaced by new credentials such as a global PKI [Faria]. 4. We also allow web-based login pages. The use of such pages is explicitly negotiated. In contrast with the existing HTTP hijack approach, our approach makes the client aware of this login requirement, making it possible to use such a mechanism even when the primary application of the user is not web browsing (such as in Wireless LAN phones). 5. The client makes explicit requests for the services that it desires, the main service being IP network connectivity. However, there is typically also a number of other services where the client can depend on the access node. For instance, the client may request the access node to perform IP address allocation on its behalf or set up security associations in order to enable other services, such as opening pinholes in an NSIS-capable firewall [Kerberos]. Exactly which services are available depends on the deployed network architecture. Several different alternatives are discussed later. 6. This channel for communication between the client and other nodes can also be used after access has been granted. For instance, if the underlying AAA infrastructure supports messages initiated by the home network, it will be possible to notify the user that his or hers pre-paid balance is running low without making a HTTP hijack necessary. Document: IST-2002-507134-AN/WP7/D02 Date: 2005-12-29 Security: Public Status: Final Version: 1.0 WWI Ambient Networks PUBLIC INFORMATION 7(14) 1.4 The New Protocol 1.4.1 Basic Exchange Figure 2 shows the NAP protocol exchange in a scenario that involves EAP, IPv6, SEcure Neighbour Discovery, and Mobile IPv6. The first part of the exchange involves the beacon and Diffie-Hellman messages. The beacon carries the hash identity of the access node and some information relating to the services it provides. Figure 2. New attachment procedure for IPv6. The second and third messages carry the Diffie-Hellman values necessary to agree on keying material. In addition, these messages are used to negotiate the security parameters that will be used subsequently. The two messages also carry the public keys associated with the peers' respective hash-based identities, and signatures that show that they possess the private keys associated with the identities. From this point on, all messages are protected using keys established by Diffie-Hellman, and the parties know each other's hash-based identities. The next four messages serve two purposes: they perform a third party-assisted authentication and authorization exchange as well as negotiating a set of services that the client gets from the access network. Our illustration shows a typical passwordor shared secret exchange that consists of an identity message, challenge, response, and acknowledgement. Such exchanges are supported by commonly available protocols and infrastructure such as UMTS SIM cards and authentication centers [AKA]. Exchanges involving a larger number of messages are also supported through the use of standard protocols such as RADIUS [RFC2865] and EAP [RFC3748]. However, NAP already supports natively some of the features (such as identity privacy) that have led to the development of these more complicated mechanisms. Document: IST-2002-507134-AN/WP7/D02 Date: 2005-12-29 Security: Public Status: Final Version: 1.0 WWI Ambient Networks PUBLIC INFORMATION 8(14) Unlike traditional network access systems, NAP does not use keys provided in EAP as a basis for subsequent data traffic. However, NAP still needs to prove the possession of these keys in its two last messages in order to thwart man-in-the-middle binding attacks [Keying, MITM]. 1.4.2 Advanced IPv6 Services NAP messages carry a number of different information elements designed to ensure secure and efficient IP service. In our example, the Beacon message carries an IPv6 prefix. This helps a moving node to choose an access node that retains its current prefix instead of another access node that does not. In the fourth message of the protocol, the mobile node requests a number of services from the access node. In the example these were Network connectivity over the wireless LAN (and possibly all the way up to a concentrator device). Address assignment, including related duplicate address detection (DAD) and multicast listener discovery (MLD) [RFC3810, RFC2462]. The interface identifier associated with the mobile node is either chosen by the access node, or, where CGAs [RFC3972] are used, generated based on the information provided by the mobile node. Information about the SEcure Neighbour Discovery (SEND) [RFC3971] router authorized to act in this particular network. Performing a Mobile IPv6 [RFC3775] home registration on behalf of the mobile node. In general, these requests fall in three categories: those involving mere information, those involving the creation of security associations with other nodes within the access network, and those involving delegation of the mobile node's tasks to the access node. After mutual authentication has been performed, the access node performs the requests and sends information about the results to the mobile node. In the case of SEND, it is sufficient to send a hash of the public key of the authorized router. In the simplest case address assignment results in an address. DHCP parameters can be necessary too, however, as DNS discovery and other services may depend on it. Also, if CGA-based addresses are used, the access node uses the mobile node's public key together with its own public key and some other chosen parameters to create a multi-key CGA [MCGA]. The access node's public key and the other chosen parameters need to be returned to the mobile node. Mobile IPv6 home registration is performed using a temporary delegation certificate signed by the mobile node, authorizing the access node to establish a suitable security association with the home agent in order to send a Binding Update. The certificate is supplied to the home network along with the authentication transaction. The certificate is considered invalid until the home network has authenticated the client and authorized the network access for both the client and the access node. This is because this type of delegation involves real-world effects, in this case changing the current location registered at a home agent. Such effects can not be committed to prior to authenticating and authorizing the different parties. Similarly, the freshness of the delegation needs to be ensured by including information from the home network's challenge. Similar designs would also work for other mobility protocols such as MOBIKE [MOBIKE] or HIP [Henderson], but the details are omitted here. NAP could even be extended to correspondent node registrations in the same manner. For instance, if the mobility protocol employs public keys (such as those in [CGACBA, Henderson]), a delegation certificate can again be used. However, as discussed in [Aura], this may be insufficient case due to the lack of a trust or contractual relationship between the mobile and correspondent nodes. To prevent flooding attacks, the claimed care-of address may need to be validated either through assurances made by the access network or another return routability test (see [Henderson] or [MOBIKE]). The former requires a common trusted root for IP address range ownership among the correspondent node and the access network, however. Where such common trust exists, the return routability test can be avoided, making it Document: IST-2002-507134-AN/WP7/D02 Date: 2005-12-29 Security: Public Status: Final Version: 1.0 WWI Ambient Networks PUBLIC INFORMATION 9(14) possible to complete even the correspondent node registrations within the same 7 message NAP exchange. 1.4.3 IPv4 Web-Based Login with Firewalls Our second example is shown in Figure 3. It illustrates how NAP works with IPv4, web-based logins and firewalls. The protocol flow has similar structure than in the previous case, but instead of a 4-message handshake the access node requests the mobile node to authenticate through a web page. The URL for this web page is communicated explicitly in the protocol, and a restricted, secure channel is opened for IP access to the indicated server. The explicit indication is necessary in order for the mobile node to bring up a suitable application and alert the user, even if the user normally employs other applications or if the applications on the device are not under human control. This also allows the access network to notify the mobile node when, e.g., paid time is about to be over and a new payment is needed. Figure 3. New attachment procedure for IPv4. Once the authentication with the web server is completed, it becomes necessary for the access node to be told that it can grant access. This can be accomplished in several ways. One common approach is that the URL provided by the access node in message five contains a session identifier and access node's address so that the web server can contact the access node using a pre-configured security association. When the access node learns that the authentication has been completed, it informs the mobile node in message six. This approach is attractive, as it requires no changes to the web browser software in the mobile node. If such changes were possible, then other approaches, such as passing SAML assertions from the web server to the client would also be possible [SAML]. Document: IST-2002-507134-AN/WP7/D02 Date: 2005-12-29 Security: Public Status: Final Version: 1.0 WWI Ambient Networks PUBLIC INFORMATION 10(14) The second difference to the first example is that DHCP is employed. The access node determines that this network employs DHCP, uses DHCP to allocate an address, and returns this to the mobile node along with other information learned through DHCP. As the mobile node needs to renew its DHCP lease periodically, the access node provides a DHCP authentication key [RFC3118]. The addressing properties of the access network are advertised early, in the Beacon message in order to facilitate intelligent decisions about handovers in a manner similar to what was already described for IPv6. In the case of IPv4, it is necessary to advertise both the local and public subnet information, as this can be used to determine whether the local or global address of the mobile node would have to be changed, and whether a global address is available at all. The example illustrates also how the system can work with firewalls, NATs, or other middleboxes within the access network. The mobile node may request information about a local middlebox and a security association to it. This allows the mobile node to control, for instance, Quality-of-Service settings or firewall pinholes using the NSIS protocol in a secure fashion. It would also be possible to delegate some of these tasks to the access node in order to reduce the number of roundtrips needed after movements. However, we have not yet explored how good tradeoff this is, as it also increases the complexity of the attachment protocol. This may be a viable approach when the access node itself is acting also as a middlebox.